Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/970

Internet Message Format | 1994-08-27 | 15.6 KB

Date: Fri, 22 Jul 94 03:11 CDT
From: [e-mail] (Evan K. Langlois)
To: [e-mail]
Subject: GEM apps, in general
Precedence: bulk


I'll post some code in my next message that handles button events.  Please
compile it.  It demonstrates soem very simple and powerful ideas.  In fact,
remove the printf's and stick in pointers to functions and you'll have a
C program that manages button events very well.  Use ObjC messages for the
printf's and it gets better.

The idea of the code is to show that you don't need to call graf_mkstate()
a bunch of times in a loop.  How many art packages look for a click and
then call graf_mkstate() in a loop?   This prevents any other events and
its wrong.  You can use timer events to animate an icon, and rectangle
events for other effects, and still recieve redraw messages and such while
a user is holding a button down - even recieve more button events!!

Now, why is holding the right mouse button down to click in a background
window archaic?  Well, I think that holding the right button will stop
a TOP message from being delivered (I don't remember nor care) and I know
that until recently, most people did not know that GEM could handle more
than one button at once without polling.

If the user clicks the mouse on a selectable and completely unobscured,
visible object, then why not select it instead of topping the window?  Since
there is a border area on most dialogs, you can use that to top it, and
and partially obscured object can be used to top the window.  I know some
of you are worried about not being to top a window - does the new condition
or forcing the object to be completely visible satisfy your needs?

As for key events and the "top" window, you should note that the top window
does always get key events - if you call a dialog a window (even a modal one).
Also note that if you select something in the menu, like change font, then
this affects the top window too .. but what if you have a dialog over that
window?   What if "Change Font" calls up a dialog in a window?  If won't
change the font of itself!!  It changes the font of a different window.
Application focus and key focus are not always different.

As for the sending of key events, I would like to propose an extension to
the drag-drop protocol.  If you implement a drag, but the application you
drag to doesn't support being dropped on, then you can still "pipe" ascii
data to that window by sending a key event to the application for each
character.  This will be painfully slow, but it will work.

As for point to type, make it an option in the app-defs file.  Its easy to
do for one application, but making it global is kinda screwy as its basically
doing finding the window, finding the app that owns the window, like drag/drop
but then it sends a copy of teh key event the OS sent to the other app.

As to Ken and WinLIB Pro:

========================================================================
I'm simply saying that the foreground application gets more 'attention'
than background tasks. No 'wasted' CPU time at all, just 're-allocated' CPU
time. After all, the application the user is currently interacting with will
be getting most of the mouse activity, don't you think? :-)
========================================================================

This statement is WRONG.  There are no foreground and background tasks.
Think of it this way.  An application waiting for an event is not running
and is not using the CPU.  An application that is executing code is
running.  Under SingleTOS, or Geneva, while one application runs, no
other application can be running, and when the AES is called, GEM begins
to poll for events and either gives an event where it needs to, or lets the
AES call return.  It determines things like how much two cuncurrent programs,
like a DESK ACC and an APP (or with GENEVA multiple apps) on a round-robin
basis, so every program gets more or less EQUAL CPU share.  Task switching
only happens during an AES call.

Under MultiTOS, multiple applications runs at once, so when does the AES
poll for events?  Answer - always.  Having programs run while another
polls makes MultiTOS seem very slow, even if only one application is
running, and more applications running means more code running at once.
What is some of those programs don't block for evnt_multi and they use
a 0ms timer to poll for events?   Well they will wind up using ALOT of
CPU time slowing the system to a baby-crawl.  Just evnt_multi calling
very often is ALOT of overhead, and then calling objc_find is worse.
Doing all this during the MultiTOS polling is too much to handle.  And
don't forget that you can have tasks that aren't GEM, and they will
have to complete for CPU time too!!

Under the newer MultiTOS, instead of polling for events, interrupts trigger
MiNT device drivers that wake up the AES and let it know an event is
available.  This is ver yfast and efficient and it means that there is no
more polling.  No polling means that when your app runs, it doesn't have to
compete with the AES code polling the mouse in a tight loop, so it runs
fast.  Also note that in neither version of MultiTOS do you need to give
up CPU time.  You can do computations all day long and never make an AES
call and the system will be fine (your windows get dirty though!).  Heavy
computation is a good reason to use tfork() - it is backwards compatible
to TOS (making it a single-tasking function call) and allow you to thread
a long function call.

Using Timer events to poll means that one application will east CPU slices
from every other program - those in windows, TOS background tasks, daemons,
or other AES programs that attempt to do concurrent tasks.  These events
are made by a programmer that assumes the user is using his program and
is not using any other, and that the performance of the rest of the system
is allowed to suffer to make his life easier.

This is simply bad programming.  There are better ways.  In General, your
programs should always sit and wait for something to happen, NOT check and
see if something is happening.  The first is highly efficient and is just
as fast under single-TOS and will free an incredible amount of CPU under
the new MultiTOS.  The second will be great under single-TOS, slow under
MultiTOS and you will see it HOG the CPU under the new MultiTOS using simple
utils like TOP.

========================================================================
I do not like the idea of having buttons function in background windows
unless that particular dialog is INTENDED to work that way.  There should
be options for doing this for things like tool boxes and multiple
non-overlapping pannels, but otherwise, I like the way GEM works normally.
========================================================================

Give examples of where the guidelines I give above fail!  Using the desktop
as a test, I only see benefits.

========================================================================
I'm not sure I follow your comment.  My -experience- is that I do not know
assembly language, and therefore have no real use for an assembly level
debugger.  What on earth can you possibly object to in that?
========================================================================

In my EXPERIENCE I have used both kinds of debuggers.  Both have their
uses.  I do know assembly language, 3 or 4 of them, but I fail to see
what ANY of this has to do with GEM.  Will using TIMER events slow the
system?  Yes!   Why?   Because the program is running instead of waiting.
Waiting means you are on a queue, ready for some other code to give you
your fix so you jive again :-)   Running means your eating CPU and if you
east CPU, you better do something GOOD with it since its limited resource.
TIMER events are sent to every app that wants them, not just the top one.
Calling evnt_multi means passing half a dozen parameters on the stack,
including lots of LEA's, then copy lots of these to the intin/intout arrays,
then lookup the control values to the calls (whoops, missed a JSR in there!
this ain't C++, so its not inline), then we call a TRAP (and that takes
forever in itself), now the return array has to have its values copied to
the pointers that were passwd, we play with some reggies, and then do a
RTS.  Evnt_multi finished, now do wind_find and objc_find and then go back
to evnt_multi.  Do all this in a tight loop, never stopping.  Why do
all this jumping around and memory copying?  Most OSs see your program
working, and other apps aren't so much, so you get lots of CPU time, and
when other apps are asking for lots of time, you get 96% or so.  When
other apps want time, you get %80, others get maybe %20, but that's about
all they need (they run slow, but useable).

Now, we do all this?  The app can wait for specific events and let programs
that NEED to use the CPU use it.  Sure, you still have to call evnt_multi
and all the rest, but not as fast as you possible can!!   That is not
event driven!   That is polling.  Polling is what made MultiTOS such a dog.
Why do it in your applications?  Don't bitch at ATARI if your gonna make
the same lazy mistakes!!

So, do us all a favor, and work to illimintae polling from your apps.

========================================================================
* I found that by collecting rectangles, it is perfectly feasible to
  blit-scroll a background window, and it is potentially faster,
========================================================================

Of course, rectangles are just 4 words, or a pointer to 4 words.  Using
them is easy.  Drawing graphics for a large pixel-map takes a considerable
amount of CPU power.  The overhead of the rectangles is nothing by
comparison.  That is why I use point-to-type and let my background windows
scroll in TOSWIN.

========================================================================
Hey, whatever happened to our discussion of color-palette handling?  I
especially likes my ideas.  :)  Could someone go back to those old
messages and digest what was discussed?
========================================================================

What was your idea?

========================================================================
A smart malloc() should use an adaptive algorithm when choosing hunk sizes
to Malloc() (I believe the current gcc libc malloc does this()).
========================================================================

8K chunks is best.   When running protected all memory is dolled out in
8K chunks anyway, so you might as well only Malloc() in that size.

========================================================================
I thought there IS a program which patched MultiTOS to do all (even in the
desktop!) dialogs in windows!
========================================================================

It's called multidial, but I don't know about the desktop.  Its a simple
program really, but so many programs call form_do() all funky that it can
be hard to configure (you can configure it per application).  I'll have to
see where to find that again.  I think I'm gonna start using it.  I don't
think it fixed the desktop though - maybe fileselector.

========================================================================
I think you have to go visit them, and slap them real hard with the
guidelines for writing multitasking-ready GEM applications.
========================================================================

1 - No Polling
2 - No vector grabbing!
3 - All graphics in windows (including window 0 with proper wind_set)
4 - Always walk rectangles
5 - Don't assume screen or memory formats.
6 - Free unused memory
7 - No polling!
8 - No vector grabbing!
9 - No form_do() or other locking calls.
10 - no dialog-ware or alert-ware

========================================================================
IMHO they provide valuable feed-back to the user, ie, "Is my program
crashed, or just taking an hour to <foo>?"
========================================================================

Buy an AdSpeed, then if it takes more than 40 minutes to <foo>, either
the application crashed, or the AdSpeed needs to be reseated and everything
has crashed.  This way I get to know if machine has dies 20 minutes early,
so I can open the machine and mess with screws for 30 minutes!  Actually,
I have since hand-bent every pin on my CPU socket to make better contact
and have had no further complaint.

========================================================================
This sort of thing is really the domain of the window manager, and should
be selectable by the user. On workstations I much prefer to have mouse
focus (window under mouse gets key events, topped or otherwise), but on the
Falcon I'm kind of used to having to top a window.
========================================================================

I think selectable by the user says it all!
========================================================================
And how do you see this working? The applications need to be changed as well,
or putting the forms in windows is going to do nothing more than giving them
a border. If you've got a form that can stay up whilst the rest of the program
is running then you're program has got to be able to accept events from it
at any time. There's no way the OS could do this for you.
========================================================================

Nope, tops go to form window, menu bar stays, but obviously, menu select
messages don't take effect until after form window is closed.  You can
top windows for other apps and run ACCs, but any top of the app that called
form_do gets that form window topped.

It works, but forms within forms (like poor pop-ups) can get messy.

========================================================================
If an ACC doesn't call menu_register, does it still take up a `slot'?
========================================================================

Depends  on the internals of GEM.  Good question!!!  I can't answer that.

========================================================================
Is there some standard way of lynching software authors, and does anyone
know Pradip's address?  (Atari Works uses forms for almost everything,
including the printing progress dialog!!!  Forget multitasking with AW).
========================================================================

Warwick!  For shame!!  You should know that the VDI is not re-entrant!
You can't switch tasks while the VDI is printing a page!   Worse yet,
the VDI writes to printer by calling the semi-re-entrant BIOS, which
means that a 1MB super-density graphics print of 1 or 2 pages will
make a BIOS call at LEAST 1 MILLION TIMES!!   BIOS is bad.  When you
need more than a couple bytes, please use GEMDOS.   GEMDOS is so much
faster, but the VDI doesn't know that, and making better VDI drivers
won't help since the VDI isn't re-entrant anyway!

Actually, I CAN spool VDI output with MiNT and my spooler, but all those
BIOS calls writing to the pipe cloggs up the system, so it takes almost
as long as printing to spool it!!   Then printing goes well, and you have
great control over that spool file, but you have to wait for it to print
AFTER you wait for it to spool :-(.  Printing happens simultaneously with
something else, but printing doesn't start until the spooling is done.
I'm not sure how to fix it, other than to drop support for /dev/centr
so I can speed up printer output.  /dev/centr locks the system so you got
to use small chunks to multitask, but /dev/lp is buffered and interrupt
driven, so I can throw a 12-24K chunk at it whenever I need to.

========================================================================
Using a form for progress is MAJORLY BAD, because it is just that time
that the user will want to switch to some other application.
========================================================================

An iconifyable window is best.

~.